Is the PrestaShop module manager throwing an XML error? Below, we explain why this is happening and how to effectively fix it – without needing to update your store or make changes to the database.
The most important ones are:
The error most often appears directly in the admin panel – in the tab Modules or after entering Module Manager. Messages can look like this:
PrestaShop sends HTTP requests to the PrestaShop Addons API to retrieve current module listings. An example endpoint looks like this:
The store expects a response in XML format. The problem arises when:
What could stop working in the panel:
Before making any changes, it's worth checking what is currently in the files. By SSH we perform
If the file is empty, contains HTML (e.g., a 503 error page) or JSON instead of XML, that is the source of the problem.
The fastest solution is to replace the content of the problematic files with minimal, correct XML. Via SSH, we execute:
You can also upload files manually via FTP. The content of each file should look like this:
To permanently block XML download attempts from the Addons API, we are creating a class override Tools. We are creating a file:
Regarding the following content:
Property $is_addons_up = false causes PrestaShop not to attempt to connect to the Addons API – and consequently, it will not download or overwrite XML files.
After creating the override file, we clear the cache. For PrestaShop 1.7 / 8.x:
You can also clear the cache from the administration panel: Advanced > Performance > Clear cache.
If we don't want to use overrides, XML files can be set to read-only. PrestaShop won't be able to overwrite them:
It's worth knowing that in a production environment, most of these features are not used on a daily basis anyway:
Recommended steps:
Contact us
What are the XML files in the config/xml/ directory?
PrestaShop stores several XML files locally that are responsible for the operation of the sections Modules > Module Manager in the admin panel. They are downloaded cyclically from an external API PrestaShop Addons and saved in the directory:config/xml/- must_have_modules_list.xml – list of modules marked as „must have” by PrestaShop
- modules_native_addons.xml – list of native modules available in Addons
- default_country_modules_list.xml – suggested modules for a specific country
- trusted_modules_list.xml - List of trusted modules verified by PrestaShop
An XML error appears when there's a problem with the structure or syntax of an XML document. It typically occurs during the parsing or processing of the XML file by software, such as a web browser, an application, or a server. Here's a breakdown of what an XML error looks like and where it can appear: **What an XML Error Looks Like:** XML errors are usually reported by the software that is trying to read the XML file. The message will typically indicate: * **The nature of the error:** This could be a "syntax error," "parsing error," "malformed XML," "invalid character," "unexpected end of file," etc. * **The location of the error:** This is crucial for debugging. The error message will usually point to: * **Line number:** The specific line in the XML file where the error was detected. * **Column number:** The position on that line where the error occurred. * **Error code (sometimes):** A specific code indicating the type of problem. * **A description of the problem:** A brief explanation of what is wrong (e.g., "element is not closed," "attribute value is not quoted"). **Common examples of specific error messages might include (these vary by parser):** * `XML parsing error: '...' is not followed by '>'` * `Error: Unclosed token.` * `XML validation error: Element '...' is not closed.` * `Error near line 10, column 5: Expected '>', but found ' '` * `Fatal Error: The element type "..." must be terminated.` **Where XML Errors Appear:** XML errors can appear in various contexts, depending on how and where the XML is being used: 1. **Web Browsers:** When you try to open an XML file directly in a web browser, if the XML is malformed, the browser will display an error message along with the line numbers indicating the problem. This is often the first place developers encounter XML errors. 2. **Web Servers/Applications:** * **API Responses:** If a server is supposed to return data in XML format but fails due to an error in its XML generation, the client application receiving the response will get an XML parsing error. * **Configuration Files:** Many web applications use XML for configuration. If a configuration file is invalid, the application will fail to start or encounter errors during its operation. * **Data Exchange:** When applications exchange data using XML (e.g., SOAP messages), an error in the XML structure of the message will cause the receiving application to report a parsing error. 3. **Desktop Applications:** Applications that read or write XML files for data storage, settings, or interoperability will report XML parsing errors if the files they encounter are invalid. 4. **Databases:** Some databases store XML data. If you try to import or query XML data that is malformed, the database system will flag it as an error. 5. **XML Editors and IDEs:** Development environments and specialized XML editors will often perform real-time validation as you type. They will highlight syntax errors directly in the editor, often with red squiggly lines and pop-up error messages. 6. **Command-Line Tools:** Tools like `xmllint` or other XML parsers used in scripts will output error messages to the console when processing invalid XML. **In summary, an XML error is a notification that an XML document violates the rules of XML syntax or structure, and it appears within the software attempting to interpret that document.**
The error most often appears directly in the admin panel – in the tab Modules or after entering Module Manager. Messages can look like this:Error found: Start tag expected, '<' not found in must_have_modules_list.xml file
Error found: Start tag expected, '<' not found in modules_native_addons.xml file
Error found: Start tag expected, '<' not found in default_country_modules_list.xml fileNote
These errors appear in PrestaShop 1.7 and PrestaShop 8.x. In older versions 1.6, the mechanism works similarly, although the location of some files may differ.
Where does this error come from?
PrestaShop sends HTTP requests to the PrestaShop Addons API to retrieve current module listings. An example endpoint looks like this:https://api.addons.prestashop.com/?version=1.7.8.x&method=listing&action=must-have- API Addons returns a response in a different format (e.g., JSON or an HTML error page).
- Connection to the API is blocked by a firewall or server configuration
- The shop server does not have access to external resources (no outgoing HTTP/HTTPS traffic).
- API Addons is temporarily unavailable or returning a timeout.
- The PrestaShop version is too old and is no longer supported by the API
Does the error affect the store's operation?
Success
The frontend of the store, shopping cart, orders, payments, and all purchasing processes are working normally. The error only concerns the admin panel – specifically the module management section.
- list of recommended modules
- „Must-have” section in the module manager
- marketplace Addons accessible from the admin panel
- Module suggestions for the country
- Slower page loading Modules (timeout when trying to connect to the API)
Step 1 – Checking the XML file contents
Before making any changes, it's worth checking what is currently in the files. By SSH we performcat config/xml/must_have_modules_list.xmlTip
You can also use the file manager in the hosting panel (e.g., Hestia CP, cPanel) or an FTP client to check the file contents – SSH access is not required.
Step 2 – replacing files with the correct XML
The fastest solution is to replace the content of the problematic files with minimal, correct XML. Via SSH, we execute:echo '' > config/xml/must_have_modules_list.xml
echo '' > config/xml/modules_native_addons.xml
echo '' > config/xml/default_country_modules_list.xml
echo '' > config/xml/trusted_modules_list.xmlWarning
Simply replacing the files will only temporarily solve the problem. PrestaShop will try to fetch data from the API again the next time the modules page is refreshed and might overwrite the files with an erroneous response.
Step 3 – Permanent Solution via Class Override
To permanently block XML download attempts from the Addons API, we are creating a class override Tools. We are creating a file:override/classes/Tools.php<?php
class Tools extends ToolsCore
{
protected static $is_addons_up = false;
}After creating the override file, we clear the cache. For PrestaShop 1.7 / 8.x:
rm -rf var/cache/dev/*
rm -rf var/cache/prod/*Info
After applying the override, the modules section still works fully – you can install, uninstall, and update modules from a ZIP file. Only the integration with the Addons marketplace in the admin panel is disabled.
Alternative – blocking file writes
If we don't want to use overrides, XML files can be set to read-only. PrestaShop won't be able to overwrite them:chmod 444 config/xml/must_have_modules_list.xml
chmod 444 config/xml/modules_native_addons.xml
chmod 444 config/xml/default_country_modules_list.xml
chmod 444 config/xml/trusted_modules_list.xmlNote
The chmod method is simpler, but it doesn't eliminate API connection attempts - PrestaShop will still perform them, which can slow down module page loading. Overriding the Tools class is a technically cleaner solution.
What don't we lose after disabling the Addons API?
It's worth knowing that in a production environment, most of these features are not used on a daily basis anyway:| Function | After the API is disabled |
| Online store frontend | It works without changes |
| Orders and Cart | It works without changes |
| Installing modules from ZIP | It works without changes |
| Module updates | It works without changes |
| Marketplace Addons in Admin | Unavailable |
| Must-have module recommendations„ | Unavailable |
| Module suggestions for the country | Unavailable |
When can the error reoccur?
If we only apply file replacement without override or chmod, the error may return after:- refreshing the Module Manager page
- PrestaShop cron job execution
- PrestaShop updates
- clearing the cache
Summary
The XML error in the PrestaShop back office is a communication issue between an old version of the store and the Addons API – it is not a server failure, a database problem, or the presence of malware. The store is functioning normally. The solution is quick and does not require a PrestaShop update.Recommended steps:
- Checking file contents in config/xml/
- Replace files with minimal valid XML
- Add class override Tools z $is_addons_up = false
- Clearing PrestaShop cache
Contact us
